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So you think you understand 
how random processes will behave? 
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The diagram on the cover represents 9 bins, each of 
which contains an unlimited number of balls, numbered 
uniformly through the indicated range. Thus, the bin at 
the bottom contains infinitely many balls numbered in 
equal quantities from 63 to 126, 


A ball is drawn at random from each bin, and the sum 
of the 9 numbers constitutes one play; call the sum Q. 


What would you expect for the distribution of the 
Q values? 


The minimum possible sum for the 9 balls is 1013 
(that is, 1+ 3 +7+15+... + 511) and the maximum 
possible sum is 2026 (that is, 2+ 6+ 14 + ... + 1022). 


The average value in each of the bins is readily 
calculated. For example, for the bin at the far right, 
there are 16 numbers to be drawn from, and they total 360; 


the average value is thus 360/16 = 22.5. The sum of the 
9 average values is 1519.5. Would you expect, then, that 
the numbers Q would average 1519.5? If so, what sort of 


variation would you expect in the Q values? 


The problem begs for simulation by computer. Each 
value of Q consists of the sum of 9 other numbers, each of 
which can be calculated as: 


W = INT((U - L + 1)*RND(1) + L) 


upper bound 

lower bound 

a random number in the range from zero to 
one, as produced by the RND function in 
many languages. 


al sp 
vou 


(The formula is taken from the book Programming in BASIC 
by Ralph Stair, Jr.) 


Thus, for the bin with the balls numbered from 63 
to 126, one number will be selected at random by: 


W = INT((126 - 63 + 1)*RND(1) + 63) 


OO 


and Q@ will be the sum of 9 such W's. [] 
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3X+1 Revisited 


The 3X+1 Problem was the opening article in our 
first issue, and has reappeared in issues 4, 13, 25, and 
4s, It seems to be time to consider Prof. Andree's 
fascinating problem once again. 


For any positive integer N, we let X = N and then 
follow this algorithm: 


Replace X with 3Xtl if X is odd; 

Replace X with X/2 if X is even; 

Repeat until X = 1; and 

Let A = the number of terms so generated. 


The process is illustrated completely for N = 9 on another 
page. 


The simple algorithm leads immediately to some 
interesting problems: 


1. Can it be proved that the algorithm will converge 
to one for any value of N? It certainly seems to do so. 
The convergence has been verified for all values of N up to 
222,000,000 by computer runs. A flowchart for such a 
run is given, Figure E, Three things are noteworthy: 


A. If the validation is made system- 
atically, taking successive values of N, then 
only odd values of N need to be tested. Any 
even value goes immediately to N/2, which has 
already been tested. 


B. The procedure need only proceed to 
the point at which X<N, for the same reason. 
In the illustration for N = 9 (Figure F), 
X becomes 7 on the fourth line, and the test can 
stop there, since 7 has already been tested. 


C. Numbers of the form 4K+1 can be shown 
to converge analytically: 


N = 4K+1 odd) 
12K+4 even 
6K+2 even 
3K+1 -- definitely less 
than N, and hence 
convergent by 
rule B above. 
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N = 9 = X, which is odd; replace with 
28 


14 


t First appearance of a string of length L. 
22 For example, a string of length 13 ends 
with the number N = 3994 (which means that 
1 it starts with N = 3982). 
34 L Ending N 
2 es 
et i: 317 
52 7 102 
391 
e 5 129 
13 9 1688 
10 (oe 
40 11 6586 
20 12 11707 
13 3994 
10 14 3000 
15 17562 
5 16 36223 
17 7099 
16 18 59709 
. 19 159134 
8 20 79611 
rofl 57877 
4 22 212181 
23 352280 
D 24 221208 
25 57370 
1 26 294938 
oe 252574 
2 530079 
weer e 331806 
terms; 30 524318 
including 
the 40 596349 
original 
value, is 
A = 20. 


The 3X+1 algorithm illustrated with 
the complete expansion for N = 9. 
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Therefore, a validation run should always begin with an 
N value of the form 4K+3 (that is, 7, or 11, or 14, or 
222,000,003, etc.) and test only every 4th N after that. 


This notion could be extended. It can be similarly 
demonstrated that numbers of the form 16K+3, or 128K+7, 
etc., must converge, but in a computer run it costs more 
to eliminate such numbers than to use them. 


D. The overflow action at Reference 3 
is important. The values of X that are 
developed can become very large relative to N. 
For example, for N = 100,000,171, a value of 
X is developed along the way of 


1,024,984,918,960, 


which is 10000 times as large as N. There is 
no reason to believe that this ratio cannot go 
even higher. Thus, if calculations are set 
up to handle, say, 16 digit numbers, then for 
values of N that are around 12 digits long, 
overflow can be expected. All calculations 
must be exact; that is, they cannot be done in 
any form of floating arithmetic. 


2. The value of A (the number of terms to convergence, 
counting the original number) can be made as large as one 
pleases, simply by taking N to be a high power of 2. For 
example, if N is the 9th power of ap Fase 512), then A = 10. 
But for odd values of N, the A values seem to be severely 
limited. The largest value ever observed is A = 1071 for 


N = 495,000,000, 000, 000, 000, 000, 000, 000, 000, 000, 037. 


The upper bound on A does not seem to increase as N increases 


in any sensible way. We have, for example: 
N = A= 
3141592653589819 456 
3141592653589820 350 
3141592653589821 456 
3141592653589822 456 


3. Consider the complete calculation for N = 28, 
shown in Figure C. It converges with A = 19. 


Since the initial X is even, the calculation 
begins by going down, to 14. For the next N, which is 29, 
the calculation begins by going up, to 88. And yet, 
those calculations come together on the fourth line, when 
X = 22, And the calculation for the next N, 30, joins 
both of those, meeting on the eleventh line. 


28 29 30 Y 
14 88 15 5 
7 4 46 

22 ———$> 22. 23 

11 70 Te "string" effect on 

34 35 consecutive values of N. 

17 106 

2 53 

26 120 

13 80 
4Q ———_—____—_. ko 

20 
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5 
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mn 
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Thus, three consecutive values of N have the same 
A value (and, indeed, go out in exactly the same way). 
These strings of equal A values reappear constantly. We 
have twice published tables of such strings, but both tables 
were in serious error. The new table, Figure F, is much 
better. The logic of sifting out such strings was given 
in a flowchart in issue 38. 


4, But the problem of finding strings of equal A 
values can be extended to a more interesting situation, 
illustrated in Table D, which summarizes this information: 


N A 

1 000 000 000 101 

1 000 000 001 163 

1 000 000 002 163 

1 000 000 003 163 2g 
1 000 000 


The circled 225 in Table D interrupts two strings of 362's, 
one of length 14, the other of length 7. Thus, there is 
a string of length 21, with one interruption. Problem: 
given a succession of A values (namely, the output of the 
3X+1 algorithm for consecutive values of N), how could one 
detect and measure such broken strings? 


5. It was pointed out that for even values of N, A 
could be made any size, but for odd values of N, A seems to 
be limited. Within that constraint, though, the inverse 
problem is unsolved: for a given value of A, is there 
always some odd value of N that will vield that value of A? 
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Further investigation into the "string" effect of the 

3X+1 algorithm was conducted at N = one billion. In 
the following table, the end value of N is given for 
strings of length L; add one billion to the N values shown. 
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101 163 
256 163 
362 486362 
362 48=—6 362 
225 362 
362 362 
362 #8362 
163 163 
225 362 
225 163 
225 225 
207 362 
163 300 


163 
256 
362 


225 
225 
362 
163 
362 
225 
225 
163 
163 


163 
256 
362 
362 
362 
225 
362 
362 
362 
225 
163 
225 
225 


163 
349 
362 
362 
362 
207 
225 
163 
225 
362 
225 
300 
362 


163 
349 
362 
362 
362 
207 
256 
163 
225 
362 
163 
300 
362 


163. 


362 
362 
362 
362 
362 
256 
163 
163 
225 
225 
163 
362 


163 
256 
362 
362 
362 
362 
256 
163 
163 
163 
362 
163 
362 


256 
362 
362 
362 
225 
362 
163 
163 
225 
225 
207 
225 
101 


The 3X+tl problem has not yet been exhausted. 
Following is a list of possible remaining work: 


1. Simple convergence (that is, the logic of Flow- 


163 
362 
362 
362 
362 
362 
163 
163 
362 
225 
207 
225 


chart E) could be extended from 222,000,000, which was the 
last verified value for N. 
program to do that would have to be able to handle integers 


of at least 14 digits. 


It should be noted, though, that 


As was pointed out, a 


the a (at tea has been applied to numbers over a tremendous 


range 
converged. 


2. Table F (the first appearance of longer lengths 


of strings) should be extended. 


3. After the logic of detecting broken strings is 
worked out, then that logic should be applied to consecutive 


values of N. 


at least up to 36-digit numbers) and has invariably 
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4. The possible limits of the ratio: 


largest X 
N 


that can develop in the process of converging should be 
explored further. The ratio cited earlier (10249.8) is 
the highest so far observed, but there has been no system- 
atic search for higher values of the ratio. 


5. An A value greater than 1071 (for odd values of N) 
can surely be found, simply by handling larger values of 
N than have been so far calculated, What needs to be 
investigated is the rate of growth of A in relation to N. 
This would probably be the most valuable piece of research 
that could be done. A concerted attack, fleshing out a 
table like the one below, might shed some light on the 
mysterious growth of the A values. 


N range Largest A Average A 
(10 to the power: ) in this range: in this range: 


. 


A THM 


The 3X+1 problem makes an excellent programming 
assignment for the last weeks of an introductory course. 
Each student can be shown how to write a program to 
calculate the A values for, say, 1000 consecutive values 
of N. This program will eventually execute some 
20,000,000 instructions and hence offers some sense of 
achievement on a non-trivial problem. The programming 
can be done in assembly language, or in integer arithmetic 
in many high-level languages. 


The problem is readily explained, and the calculations 
are easily carried out by hand for small values of N. (Each 
student should carry out the calculation for N = 27 by hand; 
it goes to 112 terms before converging.) Best of all, 
the overall problem lends itself to segmentation into five 
logical parts, as shown in Figure G. 
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Test data can be furnished (carefully selected to 
include some values that will overflow in the programs that 
the student writes). For the test data shown in Figure H, 
what is wanted for output is a tabulation: 


33 1 
TT 14 
82 1 
100 2 
126 26 
139 5 
245 2 
307 1 


One way to do this in the program is to set up a 
block of storage of, say, 800 entries; call this biock T. 
The block is to be cleared to zero in the housekeeping 
phase of the problem. Then the algorithm operates on 
each successive N, For the test data shown, the value 
N = 79100 will produce a value of A of 245, This result 
will be tallied by incrementing the contents of cell T+245. 
Then each succeeding A of 245 will tally in the same cell. 
Cell T+126, in our example, will get to 26. 


After all N values have been analyzed, the T Table 
will contain all the results in order. The subroutine 
PRINT will then output the tabulated results. 


Many computing systems gratuitously zero out blocks 
of storage for their users (a practice much to be deplored). 
To insure that the CLEAR subroutine really works, then, two Be 
cells of block T are loaded with numbers that should later 


disappear. BR tt 


STARTING N = 79100 

245 245 100 100 33. 339 126 .326. 339 139 
139 126 126 126 126 TT 12644226, (326 126 
126 126 TT Tt 126) B26) .126.-9326. Geo. 126 
126 307 TT TT TT v7" <|e6 139 TT TT 
77 77 Ti, »426. eb 82 126 Tf» 226, 126 

‘126 77 


This is your test data for the 3X+1l problem. The 52 numbers are 
the A values for the 52 consecutive values of N starting, in this 
case, with 79100. Your program should produce this same information, 


but in tabulated form. Prepare for your test run(s) by tabulating 
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Personal Computing Software 


When it became apparent in 1978 that personal computers 
were going to sell in large numbers, a peripheral industry-- 
packaged programs for these machines--sprang up. The 
predictions at that time were that: 


(a) The market was unlimited; 


(b) People were crying for programs and would 
pay anything for them; 


(c) Programs didn't have to be neat and 
certainly needed no documentation--just 
as long as they worked; 


(d) Royalties were almost impossible to predict 
because they would be so large; and 


(e) The whole business would be run honestly, 
efficiently, and in a gentlemanly fashion. 


All the people who made those predictions are now a 
lot older and wiser. It came as a big surprise to many 
people that programs could be copied, and they were. They 
were not only copied for use by friends, but some scoundrels 
even copied programs from one software vendor for submission 
to another vendor. 


The early programs ran heavily to games: endless rehashes 
of Tic-Tac-Toe, Hangman, Star Trek, and Bombs Away. Then 
we had the deluge of guess-a-number programs, and programs 
to facilitate drawing of Lissajou curves, followed shortly by 
Simulations of many casino gambling games. 


Finally programs began to be written and marketed to 
do useful, complex, and sophisticated things: medical records 
(in fact, all kinds of involved record keeping); all the 
standard problems of a small business; text editing and word 
processing; and statistical calculations. 


The customers will no longer buy shoddy programming; 
the quality standards have risen an order of magnitude or 
so just in the last six months. The pirating problem is 
still with us, but is not so severe--no one knows why. 

One possible explanation is that the level of complexity 
of packaged programs has risen significantly, and hence the 
pirates no longer understand what they're pirating, and 
hence give up. 
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I started out to list software packages that might be 
needed and marketable, and to this end, I solicited help 
from several people. 


_ Associate Editor David Babcock wrote: 


First of all, I think your question of what 
software is needed is premature. I think that 
the first question to be answered is what kind of 
software is needed. The obvious answer is 
QUALITY. But I think it goes deeper than that. 


The key word is personal. My Apple is my 
personal machine. can do with it what I want 


in the way I want. Even if I was handed well 
documented, quality software I would change it. 
And with good reason: my machine is going to be 
different from every other machine. That's a 
big reason why there are so many different 
versions of the same program around. The soft- 
ware authors may brag that their XYZ program has 
a super duper option that the others don't have, 
but what I hear them saying is "I've personalized 
my software to me," It's interesting to me 
that these same people don't understand and indeed 
feel hurt when others change their software. of 
course all of this isn't new; people have been 
customizing their cars, homes, etc., for years. 
What is different with the computer is that it is 
easy and inexpensive to do this personalizing. 


All of this leads me to some guidelines 
for software: 


1. It must be relatively inexpensive. 

2. It must be well written and well documented. 

3. Sources must be supplied. 

4, Programs should be heavily parameterized so 
that they can be easily changed. Specific 
information on how to change the program 
must be supplied. 


The above items go against the grain of 


professional software houses. They have a 
large investment in developing the software that 
must be protected. I'm not sure how to reconcile 


the conflicts, but I feel that the only way to 
get good software in the hands of the personal 
computer users is to follow guidelines like those 
I've listed, 


Or, these remarks from Larry Clark: 


What really 
Dr. Clifton 


Most of my needs/wants fall into the 


category of "what Tandy forgot." Having a bit 
of Scutch heritage, I am reluctant to buy 
what I can create for myself free. However, 


in some cases: the effort exceeds the cost. 


I have considered buying a package to 
renumber BASIC statements, but I feel that I 
can write such a program. My effort would be 
reduced if I had a listing of the TRS-80 
internals. Hence I'm trying to decide whether 
to buy or build a disassembler. In general, I 
hate to buy anything that comes without source, 
since I fear there will be some minor but 
frustrating twiddle needed. | 


High precision arithmetic wouldn't do much 
for me; I do not have the interest in numerical 
methods that you do. System software is what 
interests me primarily. If I thought there 
was a really good, disk-based editor, I'd buy 
it. Until then, I'm planning to grow my own, 
time permitting. The computer stores are 
crying for good business software, and quite a 
lot of it is starting to appear, quality unknown. 


triggered me, though, was this appeal from 
Howard of Harrington Park, New Jersey: 


I bought an Apple II last year in the hope 
that it would bring order out of chaos in the 
collected documentation I have of several 
thousand ancestors. I would like to be able to 
store, file, sort, retrieve, and cross-reference 
genealogical data. I would like to be able to 
have pedigree, individual and family group 
printouts as well as indexes. Excellent work 
in this area has been done by the LDS church, 
but they use IBM 370s. Some work out of the 
University of Utah has focussed on minis using 
an excellent soundex code with pointer systems 
for parents and progeny, but the adaptation 
to microcomputers is not clear. This work has 
relevance to tracing genetic disorders, and there 
are other analogs. If others with the same 
interest come forward, a network of information 
and knowledge could be pooled and shared. 
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The following suggestions (by Paul Lamar) appeared 
in Kilobaud Microcomputing, July, 1979: 


We suggest you don't buy software that 
does any of the following: 


1. Executes automatically after loading. 
2. Modifies the screen memory while loading. 


3. Cannot be loaded from disk using the BASIC 
DOS commands. 


4, Cannot be unlocked using the BASIC DOS 
commands. 


5. Cgnnot be listed. 
6. Cannot be changed. 
7. Has BASIC line numbers greater than 32000. 


With all these viewpoints in mind, it might still make 
sense to list some needed software. 


1. Good demonstration programs. The person who 
has just spent $1000 on a personal machine will meet--rather 
quickly--the question "Hey, what can it do?" What is 
needed here is a tape of half a dozen intelligent programs, 
such as: a complex pattern generator; some high-powered 
mathematics program (e.g., factor any given 8-digit number); 
a non-trivial game (e.g., Reversi); a simulation (e.g., of 
a roulette wheel); a program to calculate the distance 
between any two of a list of 30 cities, and between any 
one of those cities and any other point on earth, specified 
by latitude and longitude; a program to calculate the 
elapsed time in days between any two dates in the Christian 
era (this one would be quite difficult to write); and so on. 


The calculation of the day of the week, given the 
calendar date, is a commonly seen program, and if repackaged 
as a demonstation it could be spectacular. At the end of 
this article it is shown how that might be done. 


2. A high precision arithmetic Basie beg The best 
of the current packaged arithmetic systems (e.g., floating 
BASIC) run to 9 significant digits, above which they break 
out into scientific notation, but still retaining only 9 
digits. There are many situations that demand higher 
precision (see "How High the Precision?" in our issue 52). 
What is needed is a package written in machine language 

(but controlled via an interpreter) that can handle floating 
numbers of from one to, say, 100 digits. Such a package 
would run fast at one digit, but very slowly when working 
with 100 digit numbers. 


3. There has been surprising little use of animation 
in paskaged software. The microprocessor-controlled games 
at the quarter arcades make extensive use of clever animation, 
so it obviously can be done. What little animation we 
have seen so far (in Pong-type games, Bombs Away, Breakout) 
is mostly badly done and quite imperfect (e.g., the ball 
clearly hits the paddle on the screen, but it registers as 
a midst Even staid statistical programs could make good 
use of blinking, prompting, reverse video, highlighting, 
and various cursors. With the possible exception of some 
of the chess programs, I have not seen one program for sale 
that makes intelligent use of the screen capability of the 
machine. 


4, At least once a month now someone reinvents random 
number generators again and proceeds to describe, ad nauseum, 
one or two of the 9 standard statistical test of randomness. 
Someone should write a program (in BASIC, of course) to 
apply all of those tests to any given generator. 


5. We seem to be quite short of clever utility 
programs. For example, when working in assembly language, 
and things go awry (as they do), it would be nice to have 
handy a "How Did I Get Here?" search routine, to search all 
of storage for a jump to XXXX,. As has been pointed out, 
we lack properly written tools to enable us to produce 
better programs. 


6. The gambling simulations (blackjack, roulette, 
craps, etc.) should be re-done in a form to facilitate 
trying out new gambling "systems." 


7. There must be an awful lot of idle CPU time in 
the country. Some of the owners of personal machines might 
appreciate a base load problem--a problem that goes on 
endlessly, for which each user could contribute results. 

The problems that have appeared in POPULAR COMPUTING over 
the years furnish an excellent source of such base load 
problems. 


8. There are already available excellent programs 
for many machines to play chess, checkers, Kalah, bridge, 
backgammon, and Othello. The demand for such game 
programs must be high, and more should be developed. The 
game of Pasta (described in our issue 12) is a contender, 
as is Oware (a better version of Kalah--described in issue 
55), and Go-Moku (deseribed in issue 49). For that | 
matter, no one to our knowledge has tried programming a 
coaching version of chess, to teach the game. This would 
be a program in which pertinent comments would be made 
after each (human) play, of the order of: 


HE CAN TAKE THAT PIECE EASILY. 
YOUR KING IS DANGEROUSLY EXPOSED, 
THAT WAS PROBABLY YOUR BEST MOVE, 
coupled with the capability of withdrawing a move, in order 


to try another one. Such a program might make it easy to 
learn to play chess. 
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DAY-OF-THE-WEEK 


The calculation of the day of the week, given a 
calendar date, keeps reappearing in the personal computing 
magazines. It is usually presented as a novel and 
useful calculation, which is nonsense. For usefulness, 
the proper tool for the job is called a calendar. Long - 
term calendars can be found in dictionaries, almanacs, and 
even in telephone books. However, with some minor 
modifications, the day of the week calculation can be 
turned into a splendid demonstration. 


The actual calculation is best done with the classic 
formula devised by the Rev. Zeller: 


r =|[e.6n - .2| +x+o4([3 + (F] = 2c | mod 7 | 


in which F is the day of the week, given by the table: 


Sunday 
Monday 
Tuesday 
Wednesday 
Thursday 
Friday 
Saturday 
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Mis the month, with March = 1, April = 2,... 
December = 10, and January and February are 
months 11 and 12 of the preceeding year. 


K is the day of the month 
C is the century number 
Dis the year in the century. 


Thus for December 7, 1941 we have 


10 
7 

19 
= 4} 
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The square brackets, as usual, denote "greatest integer in." 


[1m adding the terms in the congruence, the sum field 
should be initialized to some high multiple of 7, like 77, 
to avoid going negative on subtracting 2C. The 
calculation of mod 7 is most easily accomplished simply 
by subtracting 7s from the sum. 


For Pearl Harbor day we have, taking the terms of Zeller's 
congruence in order: 


= 4g 


and 49 modulo 7 (the remainder on division) is 0. The 
table then gives the result, Sunday. It should be pointed 
out that the operation: 


]-[4] - 


is exactly how a computer normally does division. The 
programming (say, in integer BASIC) is rather trivial and 
execution time is fast. Too fast, in fact; the effect 

of the demonstration is weakened by the excessive speed 

of the machine. It is much more impressive if the program 
is written to call for input, such as: 


8, 23, 1963 


(for August 23, 1963. On input, the months are numbered 
in their normal order), and then pause momentarily (as 
the machine enters the mull mode) before displaying 


THE DAY IS ... FRIDAY 


But this can be made even more dramatic. When 
showing off the program, the first date chosen should be 
the current date, for which the answer is obvious. The 
second date, then, could be the same date one year hence, 
for which the person demonstrating glibly explains that 
the result, of course, will be one day later in the week 
(except if Leap Day intervenes, of course). Thus, the 
demonstration comes to the third date, which can be 
solicited from the viewers; what is needed is some other 
date for which the day of the week is known. For the 
older crowd, Pearl Harbor day pops up. For others, there 
may be a person who was born on Thanksgiving, or Easter, 


or who otherwise knows a good test case. If none is 
fortheoming from the audience, then the demonstrator 
should suddenly remember Pearl Harbor day. What the 


program produces is: 


PC79-19 


PC79-20 


Input: T2927 5. 81942 


Output: THE DAY IS ... WEDNESDAY 


followed by about 4 seconds of delay, and then: 
OOPS ... SUNDAY 


This implies, of course, calculating the correct result 
on the third entry, changing it to a wrong result, and 


wasting 4 seconds of CPU time. The latter trick can be 
as simple as: : 


510 FOR I = 1 TS 2500 
520 NEXT I 


The false result can be programmed for the third entry, 
or the input routine can be rigged to do it on any entry. 
For example, an extra space after the entry of the input date 
(unnoticed by the viewers) can be the signal to miscalculate. 


This provides an entertaining demonstration. The 
person demonstrating should, of course, then explain exactly 
what went on; we have enough misconceptions about computers 
already. 


If the program does not edit the input data, then it 
will accept a date like: 


13, 43, 1979 
and output, as it should: 
THE DAY IS ... TUESDAY 


This rounds out the demonstration, to show that output can 
be no better than the input. 


Note: Zeller's formula is good only for dates after 
1752, the year when the current Gregorian calendar was 
adopted throughout most of the world. 


